STraTOS 1997 April & May/STraTOS 1 - 1997 April & May.iso/CD01/INTERNET/SITES/RAND/ALL96.LZH/t0226/text0039.txt

Text File | 1996-03-07 | 7.7 KB | 307 lines

It seems that not everybody has MIME complaint mailers here.
So I'll send the BMCL specs once as a normal mail.

For future refernce: Please get yourselves MIME-mailers so I
or anybody else dosent need to send doubly again.

--
Elias Martenson                    [e-mail]



------------- cut here ---------------------
Bad Mood Control Language specifications
(C) 1996  Elias Martenson



**** TABLE OF CONTENTS

- ABSTRACT
- LANGUAGE SPECIFICATION
    - INTRODUCTION
    - VARIABLE DECLARATIONS
    - METHOD DECLARATIONS
    - EVENT METHOD DECLARATIONS
    - EXECUTION CONTEXT
    - ACTION PRIMITIVES
- IMPLEMENTATION
    - INTRODUCTION
    - COMPILATION




****    ABSTRACT

There has been lot of discussion on the Bad Mood mailing list
about how the AI should be done in Bad Mood. This document
describes my suggestion to how this could be solved.
This is only the first draft and should not be taken as a
definitive solution.

This document contains the specifications of a programming
language currently called BMCL (Bad Mood Control Language)
and can be used not only to control the monsters AI but
also to control other game events, like keys and other
puzzles.

This document also attepmts to make a suggestion about
how the actual code implementation will be
made (see: IMPLEMENTATION).


****    LANGUAGE SPECIFICATION

INTRODUCTION

In order to make the language efficient, we need a way to
make the BMCL code run as little a possible, while still
being able to control much of the game from it. The solution
used is to design the language as an event driven language,
which means that the BMCL code is only run when it needs to.

BMCL defines a generic entity called an Object. An object can
be either a monster, a key, a powerup of some kind or
bascially anything else. In this specification I will be
focousing on the "Monster" type object beacuse monster
control is the primary use for BMCL, at least in the
first stage.

A "#" character in the imput file denotes a comment
and causes the rest of the input line to be ignored.

An object definition looks like this:

    <object type> <object name> {
        <object definitions>
    }

The <object type> for a monster is "monster", so in order to
define the monster type "guard" the definition would look
something like this:

    monster guard {
        <object definitions>
    }

The <object definitions> is a list of methods and declarations.
Each declaration can be either of: a variable declaration,
a method or an event method.


VARIABLE DECLARATIONS

A variable declaration looks like this:

    var <name> [,<name> ...] : <type> ;

Example: in order to declare a integer variable called "foo"
for use inside the object:

    var foo: integer;

To declare the two variables "size" and "lenght" in one command:

    var size, lenght: integer;


METHOD DECLARATIONS

A method is bascially a function or a procedure for use inside
an object. A method is declared like this:

    function <name> : <function block>

The <function block> is the piece of code attached to the function
<name>. Here is an example of a method:

    function turn_and_run: {
        turn(180);    # make a full turn
        forward(0);    # run forward until hitting
                # an obstacle
    }


EVENT METHOD DECLARATIONS

An event method is basically a normal method with the difference
that is is called by the game engine at certain points (if it
has beed declared).

An event method looks exactly like this:

    event <name> [<context>] : <function block>

The available event methods is not defined
in this document but here are some examples:

init        Called once when the monster is created
playerhit    Called whenever hit by a player
monsterhit    Called whenever hit by another monster
hitplayer    Called successfully hit a player
hitmonster    Called when hitting another monster
moveobstruct    Called when walking into a wall

Here is an example event method declaration for a monster
that, when hit by a player, runs away until hitting a wall
or other obstruction.

    event playerhit: {
        turn_and_run();
    }
    event moveobstruct: {
        stop();
    }

In a complex design, one event method is not enough because
it would conflict with our goal to avoid as much BMCL code
execution as possible. For example, the definition for the
turn_and_run method would have to look like this if it
were to be used in a complex AI design:

    var is_escaping: integer;
    function turn_and_run: {
        is_escaping = 1;
        turn(180);
        forward(0);
    }
    event init: {
        is_escaping = 0;
    }
    event playerhit: {
        turn_and_run();
    }
    event hitplayer: {
        if( is_escaping != 1 ) {
            ... do something ...
        }
    }
    event moveobstruct: {
        if( is_escaping == 1 ) {
            stop();
            is_escaping = 0;
        }
    }


EXECUTION CONTEXTS

As we can see, code is executed in the hitplayer event method
just because we implemented a turn_and_run method. This is
clearly not acceptable.

To cope with this the concept of an "execution context" has
been designed.
A piece of code can be run in an specific context and is then
only affected by certain event methods.
Here is an example of the turn_and_run method when implemeted
using execution contexts:

    function turn_and_run: {
        context *escaping {
            turn(180);
            forward(0);
        }
    }
    event moveobstruct escaping: {
        stop();
    }

The asterisk in the "context *escaping" line means that the
default methods should not be called while the monster is
escaping.


ACTION PRIMITIVES

An action primitive is a built-in method that instructs
the monster to initiate a action. Actions include running,
turning around and firing the weapon.

When an action primitive is called, the action is actually
not performed, but the action is simply started. For example,
the turn(180) call used in the previous example initiates
the turn, which mean that the following forward(0) call
causes the monster to actually run and rotate at the same
time. If one wants to make the monster turn first and
then run away the code would look like this:

    function turn_and_run: {
        context *escaping {
            turn(180);
            wait(endturn);
            forward(0);
        }
    }
    event moveobstruct escaping: {
        stop();
    }

The "wait" function returns control to the game until the
certain event is called. The "end<action>" events are
events that are called whenever an action primitive
has finished.


****    IMPLEMENTATION

INTRODUCTION

This section discusses the implementation of BMCL into the
game. The first priority while designing this interface
has been to minimize the actual code execution outside
the games control. Still it will be possible for a BMCL
programmer to create code that cause the game to
hang, for example using an infinite loop.


COMPILATION

The BMCL compiler will generate a singe 68030 source file
as output. The file will declare a data structure for each
object declared in the BMCL input file. The top level
structure is a list of objects and looks like this:

    bmcl_toplevel:
            dc.l    name,object
            ...
            dc.l    0,0

<name> is a pointer to a zero terminated string containing
the name of the object and <object> is a pointer to the
corresponding object definition. The list of objects
is terminated by two NULL pointers.

An object looks like this:

    object:
            dc.l    0        ; init
            dc.l    0        ; playerhit
            dc.l    foo        ; hitplayer
            ...

That is, a list of the available event methods. Each entry
is a pointer to the actual method or 0 if it isn't used.

The generated assembler will automatically modify this
structure in case the "context" keyword is used. This
means that the only thing needed to control a monster
will be to read the monster structure for each monster
to be updated and call the appropriate event functions
to let the BMCL program update this information.

Here is an example of how the game code for the enemy hit
detection may look like:

    ; the monster structure is assumed to be
    ; available in a6, the pointer to the
    ; event method list in (a6,0) and the
    ; energy level in (a6,4)
        checkplayerhit
        beq    not_hit
        subq.l    #1,(a6,4)
        jsr    ([a6,0])
    not_hit: